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Abstract 
The Label Distribution Protocol (LDP) specification for the Wildcard 
Forward Equivalence Class (FEC) element has several limitations. 
This document addresses those limitations by defining a Typed 
Wildcard FEC Element and associated procedures. In addition, it 
defines a new LDP capability to address backward compatibility. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5918. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


LDP [RFC5036] distributes labels for Forwarding Equivalence Classes 
(FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP 
FEC TLV includes one or more FEC elements. A FEC element includes a 
FEC type and an optional type-dependent value. 


RFC 5036 specifies two FEC types (Prefix and Wildcard), and other 
documents specify additional FEC types; e.g., see [RFC4447] and 
[MLDP]. 


As specified by RFC 5036, the Wildcard FEC Element refers to all FECs 
relative to an optional constraint. The only constraint RFC 5036 
specifies is one that limits the scope of the Wildcard FEC Element to 
"all FECS bound to a given label". 


The RFC 5036 specification of the Wildcard FEC Element has the 
following deficiencies that limit its utility: 


1) The Wildcard FEC Element is untyped. There are situations where 
it would be useful to be able to refer to all FECs of a given type 
(as another constraint). 


2) Use of the Wildcard FEC Element is limited to Label Withdraw and 
Label Release messages only. There are situations where it would 
be useful to have a Wildcard FEC Element, with type constraint, in 
Label Request messages. 


This document: 


- addresses the above limitations by defining a Typed Wildcard FEC 
Element and procedures for its use. 


- specifies use of the LDP capability mechanism [RFC5561] at 
session establishment time for informing a peer that an LDP 
speaker is capable of handling the Typed Wildcard FEC. 


- specifies use of the Typed Wildcard FEC Element in a Label 
Request message. 


- specifies the Typed Wildcard FEC Element for the Prefix FEC 
Element specified by RFC 5036. 


Note that this document does not change procedures specified for the 
LDP Wildcard FEC Element by RFC 5036. 
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2. Specification Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


LDP - Label Distribution Protocol 
FEC - Forwarding Equivalence Class 
TLV - Type Length Value 

LSR - Label Switching Router 


3. The Typed Wildcard FEC Element 


The Typed Wildcard FEC Element refers to all FECs of the specified 
type that meet the constraint. It specifies a 'FEC Element Type’ and 
an optional constraint, which is intended to provide additional 
information. 


The format of the Typed Wildcard FEC Element is: 


0 1 2 3 
01234567890123456789012345678 9012 
€—————————————^A^A^A^A——^—^A^A——à——A—^—AAAW^A—»^——»—»—»—5——4—^—4—^4—2Ó2——— 
| Typed (0x05) | FEC Element | Len FEC Type | 

| Wildcard | Type | Info 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Additional FEC Type-specific Information 
| (Optional) | 
| +-+-+-+-+-+-+-+-+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 1: Typed Wildcard FEC Element 
Where: 
Typed Wildcard: One-octet FEC Element Type (0x05). 
FEC Element Type: One-octet FEC Element Type that specifies the 


FEC Element Type to be wildcarded. Please see Section 3.4.1 of 
RFC 5036. 
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Any (future) document specifying a new FEC Element Type (not 
defined in RFC 5036) should prescribe whether typed 
wildcarding is needed for that FEC Element Type. 


Len FEC Type Info: One octet that specifies the length in octets 
of the FEC Type Specific information field. It MUST be set to 
0 if there is no Additional FEC Type-specific Information. 


Additional FEC Type-specific Information (Optional): Additional 
information that is specific to the FEC Element Type and that 
is required to fully specify the Typed Wildcard. If this field 
is absent, then all FECs of the specified FEC Type would be 
matched. 


Any (future) document specifying Typed wildcarding for any 
FEC Element Type should also specify the length and format 
of Additional FEC Type Specific Information, if included. 


This document specifies one FEC Element Type instance (e.g., Prefix 
FEC) for the 'Typed Wildcard FEC Element’ in Section 6. 


4. Procedures for the Typed Wildcard FEC Element 


When a FEC TLV contains a Typed Wildcard FEC Element, the Typed 
Wildcard FEC Element MUST be the only FEC Element in the TLV. If an 
LDP speaker receives a FEC TLV containing a Typed Wildcard FEC 
Element and any other FEC elements, then the LDP speaker should 
ignore the other FEC elements and continue processing as if the 
message only contains the Typed Wildcard FEC Element. 


An LDP implementation that supports the Typed Wildcard FEC Element 
MUST support its use in Label Request, Label Withdraw, and Label 
Release messages. 


An LDP implementation that supports the Typed Wildcard FEC Element 
MUST support it for every FEC Element Type defined in [RFC5036]. 


Receipt of a Label Request message with a FEC TLV containing a Typed 
Wildcard FEC Element is interpreted as a request to send one or more 
Label Mappings for all FECs of the type specified by the FEC Element 
Type field in the Typed Wildcard FEC Element encoding. 


An LDP implementation that supports the Typed Wildcard FEC Element 


MUST support the following constraints whenever a Typed Wildcard FEC 
appears in a Label Withdraw or Label Release message: 
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1) If the message carries an optional Label TLV, the Typed Wildcard 
FEC Element refers to all FECs of the specified FEC type bound to 
the specified label. 


2) If the message has no Label TLV, the Typed Wildcard FEC Element 
refers to all FECs of the specified FEC type. 


Backwards compatibility with a router not supporting the Typed 
Wildcard FEC element is ensured by the FEC procedures defined in RFC 
5036. Quoting from RFC 5036: 


If it [an LSR] encounters a FEC Element type it cannot decode, it 
SHOULD stop decoding the FEC TLV, abort processing the message 
containing the TLV, and send an "Unknown FEC" Notification message 
to its LDP peer signaling an error. 


A router receiving a FEC TLV containing a Typed Wildcard FEC element 
for either a FEC Element Type that it doesn’t support or for a FEC 
Element Type that doesn’t support the use of wildcarding, MUST stop 
decoding the FEC TLV, abort processing the message containing the 
TLV, and send an "Unknown FEC" Notification message to its LDP peer 
to signal an error. 


A router receiving a FEC TLV containing a Typed Wildcard FEC element 
MAY also leverage mechanisms defined in [RFC5919] (say, if it had 
zero label binding for the requested FEC type, etc.). 


5. Typed Wildcard FEC Capability 


As noted above, RFC 5036 FEC procedures provide for backward 
compatibility with an LSR not supporting the Typed Wildcard FEC 
Element. However, they don’t provide means for an LSR that wishes to 
use the Typed Wildcard FEC Element to determine whether a peer 
supports it other than to send a message that uses the FEC Element 
and to wait and see how the peer responds. 


An LDP speaker that supports the Typed Wildcard FEC Element MUST 
inform its peers of the support by including a Typed Wildcard FEC 
Element Capability Parameter [RFC5561] in its Initialization messages 
only. 


The Capability Parameter for the Typed Wildcard FEC capability is a 
TLV with the following format: 
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0 1 2 3 
0:2. 3.4 5.6.7 8:901 20304556. 78: 9" 0 L2 3 4 5'6- 7 8:9 0 1 
B—R—-.——--t -4—L-- -—— L— .--.—L—4- - 4-4 - -4—4-.-4 
|U|F|Typed WCard FEC Cap(0x050B) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- LM. LM. 
|S| Reserved | 
+-+-+-+-+-+-+-+-+ 
Figure 2: Typed Wildcard FEC Capability Format 
Where: 


U and F bits: MUST be 1 and 0, respectively, as per Section 3 of 
LDP Capabilities [RFC5561]. 


Typed WCard FEC Cap: 0x050B 
Length: Two octets. It MUST be set to 0x0001. 
S-bit: MUST be 1 (indicates that capability is being advertised). 
6. Typed Wildcard FEC Element for Prefix FEC Element 
RFC 5036 defines the Prefix FEC Element, but it does not specify a 
Typed Wildcard for it. This section specifies the Typed Wildcard FEC 


Element for Prefix FEC Elements. 


The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC 
Wildcard" for short), based on Figure 1, is: 


0 t 2 3 
01234567890123456789012345678 9012 
EE 4-4-4 4-4 -p-ppapipipipipipipipipipipipig igi gigi git 
| Typed Wcard | Type = Prefix | Len = 2 | Address.. | 
EE AR————————————————— 
| ..Family | 


Figure 3: Format of Prefix FEC Element Using Typed Wildcard 
Where: 
FEC Element Type: "Prefix" FEC Element (0x02, per RFC 5036). 
Len FEC Type Info: Two octets. It MUST be set to 0x0002. 


Address Family: Two-octet quantity containing a value from the 
"ADDRESS FAMILY NUMBERS" registry on http://www.iana.org. 
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The procedures described in Section 4 apply to the Prefix FEC 
Wildcard processing. 


7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements 


There is no need to specify Typed Wildcard FEC Elements for the Host 
FEC Element specified by [RFC3036], nor for the Wildcard FEC Element 
specified by RFC 5036. The [RFC3036] Host FEC Element has been 
removed from RFC 5036, and the Wildcard FEC Element is untyped by 
definition. 


In other words, the ’FEC Element Type’ field in ”Typed Wildcard FEC 
Element’ MUST NOT be either 0x01 or 0x03. 


8. IANA Considerations 


This document introduces a new LDP FEC Element Type and a new LDP 
Capability, both of which have been assigned by IANA. 


IANA has assigned a 'Typed Wildcard FEC Element’ code point (0x05) 
from the LDP FEC Type Name Space. [RFC5036] partitions the FEC 
Type Name Space into 3 regions: IETF Consensus region, First Come 
First Served region, and Private Use region. The code point 0x05 
is from the IETF Consensus range. 


IANA has assigned a 'Typed Wildcard FEC Capability’ code point 
(0x050B) from the TLV Type name space. [RFC5036] partitions the 
TLV TYPE name space into 3 regions: IETF Consensus region, Vendor 
Private Use region, and Experimental Use region. The code point 
0x050B is from the IETF Consensus range. 


9. Security Considerations 


No security considerations beyond those that apply to the base LDP 
specification [RFC5036] and that are further described in [RFC5920] 
apply to use of the Typed Wildcard FEC Elements as described in this 
document. 


One could deduce that the security exposure is reduced by this 
document, since an LDP speaker using the Typed Wildcard FEC Element 
could use a single message to request, withdraw, or release all the 
label mappings of a particular type (a particular Address Family 
Identifier (AFI), for example), whereas an LDP speaker using the 
Wildcard FEC Element, as defined in the base LDP specification 
[RFC5036], could use a single message to request, withdraw, or 
release all the label mappings of all types (all AFIs, for example). 
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